Caching has always been an important part of the HTTP protocol, which specifies the behavior of clients, servers, and proxy caches. The content server receives an HTTP request for a URL that includes an HTTP request header. The following are two exemplary request headers:                GET/HTTP/1.1        Host: www.somewhere.com        X-MSISDN: 0124356789        User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; QFE 123456) and        GET/ HTTP/1.1        Host: www.somewhere.com        X-MSISDN: 9876543210        User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1).        
Once the content server receives the request, the content server can determine whether to cache the content data related to the requested URL at the user agent or an intermediary cache. If the content server determines not to cache the content data, the content server appends the appropriate response data header to the response data transmitted to the appropriate device, such as the user agent.
If the content server determines that the content data is to be cached, the content server would append the appropriate response data header to the response data and transmit the response data to the cache to be stored for a configurable amount of time. But this created a significant problem at the intermediate cache because the content server can provide two users who request the same URL with the wrong content data. For example, the two exemplary requests provided above could result in different content data. If an intermediate cache was not aware of the difference, cached content data from the first request header data could be transmitted to the second user agent requesting the same URL with a second header data. Because of the differences between the content data, the second user agent could receive faulty content data so that the second user agent would not provide the correct data to the user. In other words, the cache could not distinguish between this content data. To address this problem, a “Vary” response header was created to allow the content server to notify the cache of response headers that could directly affect the content data. For example, the exemplary request headers, shown above, inform the content server the browser name, version, etc. that is requesting the content. A rich browser (one that supports many internet standards) may get response data that is full of rich content, while a limited browser (one that supports few internet standards) may get a much simpler response.
Unfortunately, while the request header data is important, the “Vary” response header method does not inform the intermediary caches how the values in the “Vary” header are used. For example, using the same two exemplary request headers:                GET/HTTP/1.1        Host: www.somewhere.com        X-MSISDN: 0124356789        User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; QFE 123456) and        GET/HTTP/1.1        Host: www.somewhere.com        X-MSISDN: 9876543210        
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1),
that can have the same response header data (as provided below), but with different content data (even if the content data is substantially similar):
                HTTP/1.1 200 OK        Vary: User-Agent, X-MSISDN        Content Length: 1000        Expires: Thu, 1 Dec. 1994 16:00:00 GMT.        
The “Vary” response header instructs the intermediary cache that the content data for this response is cacheable, but may be different for requests with different values within the request headers data of “X-MSISDN” and “User-Agent”. For an HTTP compliant intermediary cache, if the user agent downloads the URL http://www.somewhere.com/ and the intermediate cache caches the response, then a second request with different values for the HTTP request headers “X-MSISDN” and “User-Agent” cannot re-use the cached content data even if the content data corresponding to the second request is the same or substantially similar to cached content data. Because this second request was not matched to the cached content data, the response data corresponding to the second request is stored in the intermediary cache as well. Consequently, the cache could have hundreds or thousands of entries for content data that are the same or substantially similar. This results in inefficient use of the intermediary cache.